Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(email) allow for custom mail implementations #10376

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

JipSterk
Copy link
Contributor

☕️ Reasoning

currently solutions using a custom configuration of sendVerificationRequest for the nodemailer provider still require a server config object passed even though it's type is not mandatory which is not need for implementations that for example use a sdk like aws-ses or react-email

🧢 Checklist

  • Documentation
  • Tests
  • Ready to be merged

🎫 Affected issues

📌 Resources

Copy link

vercel bot commented Mar 21, 2024

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
auth-docs ✅ Ready (Inspect) Visit Preview 💬 Add feedback May 29, 2024 1:24pm
1 Ignored Deployment
Name Status Preview Comments Updated (UTC)
next-auth-docs ⬜️ Ignored (Inspect) Visit Preview May 29, 2024 1:24pm

Copy link

vercel bot commented Mar 21, 2024

@JipSterk is attempting to deploy a commit to the authjs Team on Vercel.

A member of the Team first needs to authorize it.

@github-actions github-actions bot added providers core Refers to `@auth/core` labels Mar 21, 2024

return {
id: "nodemailer",
type: "email",
name: "Nodemailer",
server: { host: "localhost", port: 25, auth: { user: "", pass: "" } },
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i couldn't figure out why this server object was needed outside of development purposes

@ndom91
Copy link
Member

ndom91 commented May 19, 2024

I think this PR is no longer necessary. We shipped multiple http request Email providers (which can be extended). Can you check out these links and let me know if that covers it for yuo?

@JipSterk
Copy link
Contributor Author

hi @ndmom thanks for the suggestion, i haven’t stumbled upon this page in the docs and it seems like this is exactly what i want! however when i define an object with the same properties the typescript compiler will complain that the following properties are missing: name, from, maxAge and options which is of the EmailUserConfig type with basically the same options. i assume these aren't required? if so i can update the pr which makes these properties optional to reflect the example on the docs. just to make sure but these are the versions i use:

"next-auth": "5.0.0-beta.18",
"@auth/core": "0.31.0",

@ndom91
Copy link
Member

ndom91 commented May 22, 2024

@JipSterk which object are you referring to that's giving you TS issues? Could you provide some code example or point to the relevant piece in the example pages I linked to above?

Also what are you using @auth/core for exactly? That shouldn't be necessary to install, only next-auth, for example 🤞

@JipSterk
Copy link
Contributor Author

JipSterk commented May 23, 2024

that would be EmailConfig it requires the properties mentioned above which are: name, from, maxAge and options. in the example shown on the page you mentioned these properties are not defined so is the example wrong or could these types become optional?

@ndom91
Copy link
Member

ndom91 commented May 28, 2024

@JipSterk thanks for pointing this out, it looks like both could use a bit of updating.

  1. The example should include most of those fields.

    • maxAge is important for defining how long the verificationTokens should be valid. Although we could safely default to something like 24hrs in the @auth/core code..
    • name is just the name of the provider that by default gets put into the btn on the login page, like "Login with X"
    • options we don't really need in this situation actually and can be made optional
    • from is also potentially optional depending on how you implement the sendVerificationRequest function yourself. If you hardcode a from address, like in the example in the guide link from above, then you don't need to pass it in at the provider level here.
  2. So regarding the types..

    • from can be made optional
    • optoins can be made optional

I've updated the guide to show the use of maxAge and name. Could you cover the type updates?

I dont thinkt he changes to the nodmeailer provider in this PR are necessary anymore, right? What do you think?

EDIT: Just noticed that maxAge does fall back to 24hrs already (packages/core/src/lib/actions/signin/send-token.ts:57), so that can be made optional as well in TS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Refers to `@auth/core` providers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants